Different types of sensors are commonly used today for automatically monitoring conditions in certain environments. The sensors may be adapted and used for measuring various properties such as temperature, pressure, humidity, noise level, oxygen level, traffic density, and so forth. The environments monitored by sensors in this way may include any indoor or outdoor locations of any size, such as limited rooms requiring controlled conditions or more open spaces and locations of interest, as well as particular “objects” such as machines or humans. Some examples of sensors are temperature sensors used for controlling ventilation systems in a building, oxygen level sensors used for controlling agriculture conditions, and humidity sensors used for weather observations.
It is also useful to employ a common network with multiple sensors to serve a range of different users having different objectives and methods for making use of the measurements and observations delivered by the sensors. Such sensor networks may therefore become quite large and complex, e.g. including several different types of sensors installed at different locations, as well as communication links, gateways and servers for collecting and conveying observation results from the sensors to appropriate receiving parties.
The end-receivers or “consumers” of such measurement results from sensors may include any humans, automatic applications, control and monitoring systems, that have requested for or subscribe to the sensor information, in the following referred to as “data users” for simplicity which could be any parties without limitation to the described examples. Further, any measurements and registrations that can be made by such sensors in this context will be referred to as “observations” without limitation to the described examples.
FIG. 1 illustrates schematically how a network of sensors 100 is used to provide observations to data users according to regular procedures. A first action 1:1 shows that sensor data from the sensors 100 is received and stored in a data collector entity 102 which is typically a server or the like including equipment for communication, processing and data storage. In this example, the data collector 102 performs some kind of analysis and processing of the received sensor data, in an action 1:2, in order to create and compile different reports of the sensor observations for different data users.
Further, a number of interfaces 102a, in this example Application Programming Interfaces, APIs, are configured in the data collector 102 to deliver the observation reports individually to various data users 104, as schematically shown by an action 1:3. The data users 104 in this example include a website e.g. for publishing weather forecasts, a control application e.g. for monitoring and controlling some apparatus or process depending on the measurements, and an information centre e.g. providing information and predictions on the road traffic situation.
Typically, the data users are not aware of what type of sensors are used for their reports, how they measure, and how/where they are set up in detail. Basically, the data user's main interest is that the resulting information is delivered from the APIs 102a and also that it is accurate and can be trusted. However, some sensors may provide incorrect data resulting in reports that inaccurately reflect the environment being measured or otherwise observed. This inaccuracy may be caused by malfunctioning hardware or software in the sensors, and/or faults in the components and network used for distribution of the sensor data.
It is therefore a problem that data users are not able to estimate whether a received report is reliable or not. Sometimes the data users may get conflicting information from different sensors, not knowing which information can be trusted. There are various methods and arrangements available for discovering faults in the sensor and distribution equipment, such as discovering that one of several sensors at the same location provides a measurement that deviates from the others. Measurement results from one or more sensors may also be analyzed in a more or less sophisticated manner, e.g. over time, to detect any abnormal or strange behaviour. The suspected faulty sensor may then be visited on location for further investigation. For example, a temperature sensor that suddenly reports an unexpected temperature can be inspected by going out with a thermometer to measure the correct temperature manually at the sensor location.
However, a faulty sensor may nonetheless go unnoticed and will thus continue to provide erroneous measurements and observations without being discovered. The above methods further require a certain amount of efforts and extra equipment and are executed mainly to recognize and exchange faulty equipment, while it is still a problem that data users have no way of knowing whether a delivered measurement report can be trusted or not.